Design and Deployment of Service Oriented Applications with Non- Functional Requirements1

Service-Oriented Architectures (SOA) provide a flexible and dynamic platform for implementing business services. Due to the rapid increase in the number of available services, more emphasis is put on their reliability, availability, security, etc. In order to meet such non-functional requirements, a service needs to be designed for reliability by making design decisions on an architectural level. Recently, various non-functional parameters of services have been identified by various XMLbased web service (WS) standards such as WS-Reliability, WS-ReliableMessaging, WS-Security, etc. While these properties are attached to business-level web services, they, in fact, specify the configuration and behavior of the service infrastructure, i.e. services that are not part a specific application, but play a dedicated role in the underlying service middleware. A focal issue in the service infrastructure is to provide reliable messaging between services, where the reliable delivery of a message can be transparently guaranteed by the underlying platform. Non-functional properties are captured at a low implementation-level by using dedicated XML deployment descriptors. This is unfortunate since the core business functionality of a service is typically designed using high-level visual notations like the Unified Modeling Language (UML) or the Business Process Modeling Notation (BPMN). As a consequence, service configurations cannot be designed at a high architectural level. Up to very recently, Web services messaging standards used to capture a different subset of non-functional parameters making even closely related standards incompatible with each other. For instance, the definition of timing parameters or message ordering (e.g. InvokeInOrder parameter) was different in the WS-ReliableMessaging and WS-Reliability standards, although the underlying concepts were closely related. While recently, WS-ReliableMessaging has evolved to being the de facto standard for reliable message delivery, the standard is continuously subject to minor, non-conceptual changes, which complicates the maintenance of existing configuration files. Furthermore, each middleware typically implements the standard with middleware-specific extensions. As a consequence, the portability of service configurations is also problematic.